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TITLE: Computerized insurance premium quote request and policy issuance system 



Brief Summary Text ( 3 ) : 

Prior to the invention described below, insurance underwriting has been conducted 
primarily by manually reviewing and evaluating voluminous and often redundant 
client information and application forms. These forms are normally supplied by each 
insurance company to individual agents in the field and must be updated and/or 
replaced periodically in response to changes in individual company's standards or 
legislative enactments in the state in which the insured risk resides. Typically, 
each insurance transaction, application, or request for information requires a 
separate document to be filled out by the client and/or agent. Due to the general 
nature of these forms, much of the information entered by the client or the agent 
is redundant and serves only to contribute to the tremendous volume of paper which 
must be transmitted and reviewed in order to create an average insurance policy. 
When changes and supplements to information previously given by the client are 
necessary, even more forms and duplicate information are generated, which further 
contribute to the mass of information previously submitted. This is because, in 
order to transmit new information to the proper file, these change or supplement 
forms require the entry of client and/or risk information previously submitted on 
application forms already in the clients file. 

Brief Summary Text (4) : 

This system as it now exists is inefficient and time consuming for the client, the 
agent and the underwriter . It is especially time consuming for the underwrieer 
because of the volumes of forms and information that must be reviewed for errors, 
non sequiturs, insufficient and/or incomplete information regarding the client or 
the risk to be insured. If any of these deficiencies are identified, the 
underwriter must draft and send correspondence to the agent or the client in order 
to correct, clarify or supplement the underwriter files. Once the files have been 
placed in proper order, the specific client and risk information are manually 
combined into a policy which then is submitted to the individual client for his 
review and approval . 

Brief Summary Text (6) : 

The Insurance Institute for esearch (IIR) has proposed a common application form 
for each type of personal insurance, in an attempt to overcome some of the 
difficulties inherent in current insurance underwriting methods. These forms 
theoretically could be recorded in the memory system of an agent's personal 
computer so that they could be filled out electronically and the data sent to an 
insurance carrier in a "batch" environment. As used herein, the expression "batch" 
means a plurality of separate insurance transactions and/or information entered 
during a single operation of a terminal. The basic thrust of the IIR has been the 
creation of standardized application forms and records which can be used with any 
insurance carrier and which can be sent to a carrier in a batch input record. This 
proposal, however, still suffers from the same problems as those encountered 
previously. For example, the application forms of the IIR system require the entry 
of client and risk identification information each time an application form is 
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filled out; and these application forms must still be edited and reviewed by the 
underwriter who must continue to conduct the aforementioned error analysis as well 
as the insufficient or incorrect data analysis mentioned above. 

Brief Summary Text (23) : 

In most instances, concurrently with the writing and mailing of the insurance 
contract to the client, the information included in the original application is 
electronically stored and displayed, on request to underwriter personnel. Should 
the underwriter decide not to proceed with the insurance, it is cancelled. 
Alternatively, should the underwriter decide to make variations, he may do so 
electronically, and these variations appear in a subsequently printed and mailed 
policy. Before actually proceeding with the printing of the insurance contract, 
data included in the insurance application is electronically and automatically 
compared to certain underwriting criteria and if any of these standards is 
exceeded, the aforementioned underwriting function is carried out before the 
insurance contract is printed and mailed. That is, in the first-mentioned case, 
underwriting is carried out concurrently with the issuance of the policy. In the 
second-mentioned case, a "pre -underwriting " operation is carried out before the 
policy is mailed; this pre -underwriting step being triggered by certain data that 
exceed the insurance company standards . 

Drawing Description Text (11) : 

FIG. 9 is a menu displayed to an underwriter in order to institute underwriting 
activity; 

Detailed Description Text (4) : 

The first function, termed the input function, generally is the entry point for the 
overall system. Prior to entry into the system, however, certain preliminaries must 
be accomplished. The source of most insurance information requests comes from 
agents, either by telephone, mail or agency-company communications, or from 
company-generated mailings. The initial processing of these requests generally 
consists of: manually stamping submitted client application documents with the date 
received and checking for return name and address; entering applications and 
assigning client numbers, as well as checking for existing client numbers; 
reviewing the submitted documents for minimal information which must be provided in 
order to initiate processing by the system; and collecting certain statistics such 
as dates, types of business, sources of business, and pre -underwriting criteria for 
use in reviewing system output. These preliminary steps, although advantageous with 
this embodiment of the invention, are not necessary to use the system to its best 
advantage . 

Detailed Description Text { 6) : 

Once the user has entered his access password and it has been verified by the 
system, he then chooses the type of transaction which he wishes to carry out. There 
are two basic types of transactions: one which is multi-client related, such as a 
review of all items which have been entered and stored over a designated period, 
for example two weeks; and one which is single-client related, such as the entry of 
a premium quote request or policy request. For single-client related functions, the 
client must be identified to the system and in the case of existing clients or new 
clients with incomplete information, data must be entered or ceded from available 
files in the central processor data bank. In this embodiment of the present 
invention there are provided five files into which data is entered and from which 
data is taken. These files include a prospect file which contains premium 
quotations that have been previously offered and/or refused by a client. The 
prospect file also contains current client information for the purpose of 
writingadditional coverages. A suspense or storage file is provided for general 
underwriting purposes to maintain reports (such as motor vehicle reports or 
inspection data), binder, mail, high authority approval, diary, rate hold, early 
submissions and errors. This file also includes premium quotations which are 
awaiting client approval to finalize the insurance contract. The data bank also is 
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provided with a file which provides a facility for electronic documentation (and 
storage if necessary) of individual policies. An inquiry file provides a facility 
to review current policy information, premium quotations, and work in process. 
Finally, there is provided a client file which is used to identify individual 
clients. This file normally contains all data available on the client. This data is 
provided either by ceding available client information from existing files or 
inputting mandatory client information such as client name (last, first) , client 
address (street, city, state, zip code) and identifying number of the originator of 
the insurance, for example, the agent or broker (this is the access number provided 
by the company for accessing the system) . 

Detailed Description Text (8): 

The provision of the electronic input function allows a company to speed the turn 
around time from the time an application is received until the time it is written 
or declined. Further it allows the company to track applications from the time of 
entry through final processing to facilitate follow ups where necessary. Also, the 
input function allows a company to scan input information and stored data to 
collect statistics which help determine whether the criteria for sending 
applications to underwriting are realistic. 

Detailed Description Text (11) : 

The third function provided by this embodiment of the computerized insurance system 
is entitled the underwriting approval function. In general, all policy requests 
must be approved by the underwriter . In many cases insurance policies do not have 
to be approved before they are issued, but can be issuedaand underwritten 
concurrently. Underwriting usually requires the entry and editing of entered 
information for integrity and completeness, the ceding from the data file of 
information which is not provided on the submitted application as well as certain 
characteristics of the risk to be insured which are entered into the data bank, the 
checking of the suspense file to determine if there are any motor vehicle reports 
and/or inspections outstanding (if not, and there is sufficient information 
entered, such reports are ordered from the appropriate state agency by the 
underwriter ) , and displaying the client's quotation request for criteria that might 
require p re -underwriting instead of concurrent underwriting . Insurance policies 
that require p re -underwriting include requests that require advice from other 
underwriting branches because of an out-of-state location or requests that include 
risks which must be approved because they exceed an underwriter 1 s authorized limit. 
If p re -underwriting is required, the request for an insurance policy is suspended 
before being forwarded to underwriting . 

Detailed Description Text (12) : 

It will be apparent to one skilled in the art of insurance underwriting that 
certain criteria and particular limitations may be chosen by the individual 
underwriters as lines of demarcation for risks which may be concurrently 
underwritten and risks which require underwriter approval prior to issuance of the 
policy. Examples of such limitations or lines of demarcation include requests 
wherein the named insured differs from the individual's and/or spouse's name, where 
more than five automobiles are requested on an automobile or excess liability 
policy, where $400, 000 or more coverage is requested on a dwelling for a home owner 
policy, or $100,000 or more coverage is requested for jewelry on a "personal 
articles floater (PAF) policy or where a single scheduled jewelry item on such a 
PAF is insured for $50,000 or more, etc. 

Detailed Description Text (13) : 

The benefits of the underwriting approval function include allowing an underwriter 
to be advised of those risks which need approval while allowing all other risks to 
be concurrently processed by the system. 

Detailed Description Text (15) : 

The fifth function provided in this system is termed the underwriting notification 
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function and is provided by an underwriting data base (within the central 
processing data base) capable of storing client and risk information on current 
policies as well as underwritten business. This underwriting data base is used to 
facilitate risk evaluation and underwriter action. The data base is comprised of 
fourteen components including: 

Detailed Description Text (16) : 

(1) A decline/cancellation file which contains basic policy information on risks 
declined or cancelled based upon underwriting criteria and/or risks cancelled at 
the insured's request. 

Detailed Description Text (18): 

(3) A suspense file (the same file as discussed above with regard to the input 
function) which is a general underwriting suspense file for reports, binders, mail, 
higher authority approval and diary information. This file is provided in the event 
that the underwriter may require furthe information about a risk after the policy 
had been issued but before giving final approval. In that case the items will be 
suspended for post-issuance underwriting . 

Detailed Description Text (19) : 

(4) A premium modification file to permit changes to a premium. By utilizing this 
file, existing premium rates are adjusted up or down by a percentage determined by 
the underwriter . This file represents the criteria and technique for premium 
adjustments and is submitted to state insurance authorities and will provide the 
underwriter with a format to adjust rates on the policy either prior to issuance or 
by endorsement. 

Detailed Description Text (21) : 

(6) A loss information directory, which notifies the appropriate underwriter of the 
occurrence of a loss, utilizes a loss data base within the central data base. There 
is also provided a directory for the claims department of a typical insurance 
company to notify the appropriate underwriter of an unusual loss when it occurs. 

Detailed Description Text (22) : 

(7) Manual ordering of reports components which allow the "off-cycle" report 
ordering by underwriters at their discretion. In this context "of f -cycle" refers to 
soliciting documents and reports such as appraisals or MVR reports manually outside 
the scope of the system. 

Detailed Description Text (23) : 

(8) An underwriter approval directory wherein the underwriter may approve 
concurrent and non-concurrent transactions. For non-concurrent (p re -underwritten ) 
transactions, exception explanations are required and approval "triggers" issuance 
or endorsements. 

Detailed Description Text (24) : 

(9) A cancellation capability wherein an underwriter may execute cancellation 
transactions which, in the prior art were performed by a separate branch of the 
insurance company on instructions of the underwriter . In the present system, all 
policy requests which are not approved by the underwriter are either declined or 
canceled depending upon whether or not those policies have been issued. If the 
request requires pre -underwriting or has not yet been issued, the underwriter may 
decline all or part of the risk. If so, the declination and its reasons are entered 
in the declined file. If, on the other hand the policy was issued, the underwriter 
may decline a risk by requesting cancellation. This information also is entered in 
the declined file. In addition, the prospect file is updated to reflect any risk 
that has been declined. 

Detailed Description Text (25) : 

(10) A non-renewal file for streamlining non-renewal. Currently, an underwriter 
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initiates non-renewal by completing an " Underwriter Action Entry Form" (UAEF) . As a 
result, a policy otherwise in condition for renewal is not renewed, and the reasons 
and numbers of policies not to be renewed are entered on a "DO NOT RENEW" (DNR) 
control list. From this list, the "operations" department of a typical insurance 
company types up and mails appropriate non-renewal notifications to the insureds. 
The present system allows direct entry by an underwriter of the DNR order, thus 
eliminating the need for completion of the UAEF form and the requirement that it be 
entered by the operations department. It is, however, preferred to produce a DNR 
control list for management and quality control review. 

Detailed Description Text (26) : 

(11) A reinstatement file which operates in a manner similar to the cancellation 
method set out above and which allows the underwriter to approve and directly enter 
input reinstatement orders to the system for processing without requiring that 
those orders first be forwarded to operations for input. 

Detailed Description Text (28) : 

(13) A contract modifications file which permits an underwriter to modify a policy 
through manuscript endorsement on the policy itself and/or separate endorsement. 

Detailed Description Text (29) : 

(14) A self-audit file which allows access to data within the central processing 
data bank for the purpose of evaluating underwriter /department judgment and/or 
results. 

Detailed Description Text (30) : 

The benefits of this elaborate underwriting notification function are that it 
eliminates the requirement for manually preparing and maintaining 

Decline/Cancellation Files, Prospect Files, and Suspense File Report ordering, as 
has heretofore been necessary. It further reduces Cancellation, Non-renewal and 
Reinstatement procedures to a single ste which improves efficiency and service. 
Also, this function simplifies Premium Modification and the Consent to Rate Change 
for the underwriter while, at the same time, providing management reports regarding 
underwriter /branch performance. 

Detailed Description Text (32) : 

Since it is possible for more than one quotation to exist on a given policy, it is 
necessary that the accepted quotation be indicated. A suspense file is created for 
those quotations which are pending approval by the insured, thus notifying the 
underwriter that a quotation was given. (The function of this file may be combined 
with that of the prospect file.) Once the quotation has been accepted by the 
insured it of course is stored as an integral portion of the policy. Preferably, 
those quotations which have not been accepted may be stored for a designated period 
subsequent to the issuance of the policy, for example, 30 days. After the policy 
has been issued, pending quotations are purged. 

Detailed Description Text (34) : 

The seventh function provided by this system is designed to carry out follow-up 
procedures related to policies. These procedures are provided as a combination of 
manual and electronic functions. The manual functions include the mailing or 
transmission of policies, endorsements, cancel/reinstatement notices, DNR notices, 
motor vehicle reports (MVR) , inspections, etc. The electronic functions include 
electronic mail, links between underwriting and other operations, suspense follow- 
up, premium reporting and direct billing. 

Detailed Description Text (35) : 

The eighth function provided by this system relates to the changing of rate filings 
and rules. In order to insure the continued profitability and efficiency of 
insurance underwriting, the system responds quickly to rate and rule changes. 
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Detailed Description Text (38) : 

The central processor 23 is also coupled to various other remote terminals for use 
by other insurance company departments such as operations 25 or underwriting 27. 
These terminals are also equipped with keyboards to allow communications with the 
central processor 23 and to permit referrals between terminals e. g., a particular 
request 24 once acted upon by the operations department 25 may be referred, at 26 t 
underwriting department 27 for approval directly through the data base. Statistical 
and quality control information may also be extracted from the data base within the 
central processor by those having authorized access to the necessary data base (not 
shown) . 

Detailed Description Text (39) : 

The central processor 23 is provided with storage capacity to obtain and review the 
laws and regulations of various state agencies having governmental control over 
insurance transactions. Such laws and regulations, as mentioned above, control 
policy minimums, limits, etc., and, of course, are of particular interest to agents 
and underwriters in the various states. Further, as these laws and regulations 
change, users of this system are promptly apprised of such changes. 

Detailed Description Text (41) : 

Another advantageous feature of the present invention, as discussed in greater 
detail below, is that the various insurance transactions, and the operations and 
underwriting functions used to carry out those transactions, are "menu-driven". 
That is, the central processor is programmed to display on the VDT, a "menu" of all 
insurance functions that may be carried out by the user. This central processor is 
programmed to provide, upon the selection by the user of a particular one of those 
insurance functions, further dssplay of a "sub-menu" of those selectable functions 
or transactions which fall within the scope of the transaction selected from the 
initial, or "main menu". The "display screen" of the main menu for the agent, 
operations and underwriting functions are illustrated in FIGS. 7-9 respectively. 

Detailed Description Text (44) : 

Beginning at the top of FIG. 2, a user signs on at 40, by entering his name and/or 
his authorization code number at a terminal which communicates with the central 
processor. This entered information is checked at 42 to determine whether or not 
the user is authorized to enter the system. If the user is not authorized to enter, 
the system rejects his entry, at 44. If authorization is verified, the central 
processor determines, at 46, which level of authority to which the user is 
entitled. In this embodiment of the present system, three (3) levels of authority 
are selectively available to a user: the operations level 48, the underwriter level 
50, and the agent level 52. The agent level 52 also is accessible by systems 
troubleshooters and engineers. If the operations level 48 is accessed, an 
operations decision step 54 is executed to determine precisely what function is to 
be carried out. These functions are discussed in greater detail below and are 
indicated generally at 55. If the user accesses underwriter level 50, there is 
provided an underwriting decision step 56 to determine the underwriting function to 
be provided. This underwriting function is also detailed below and indicated 
generally at 57. 

Detailed Description Text (48) : 

Once the system has generated a policy which is accepted at 82, the system proceeds 
to the issue step 90 wherein the contract components are customized, at 92, 
according to the individual risk and/or client information; and the overall policy 
is reviewed for underwriting, at 94. Test 96 evaluates the customized contract for 
the presence of predetermined characteristics which indicate the need for further 
approval. If any of these predetermined criteria are present, the policy data is 
sent to the underwriter for modification, approval and/or refusal, as at 98. This 
evaluation by the underwriter is indicated generally at 100 and is discussed in 
greater detail below. Should the policy not need further approval, it is sent to a 
batch system 102 for printing and for determining, at 106, what further documents 
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are necessary to prepare or obtain in conjunction with the contract. Examples of 
such documents are premium reports, MVR reports, appraisals, quality control and/or 
bills or countersigning. This process is indicated generally at 104 and discussed 
in greater detail below. Once the system has proceeded past this point, underwriter 
approval is granted at 108. 

Detailed Description Text (49) : 

FIG. 2C shows a detailed schematic flow chart of the underwriting function referred 
to at 57 in FIG. 2A. Entry to this portion of the system is similar to entry into 
the agett's level in that a user signs on and the menu for underwriting 50, which 
contains a list of the underwriting functions available, is displayed. Once this 
display is complete, an "in-box" containing work to be performed is displayed, at 
110. The underwriter evaluates, at 112, the work to be done and scrutinizes the 
displayed reasons for which the item of work was submitted to the underwriter . 
These reasons and the policy inquiry 116 are evaluated and the underwriter 
determines at 118 if the policy can be authorized at this level. If the policy 
cannot be authorized at this level it is sent to a higher underwriting authority 
120 wherein a similar series of steps 122 are performed. If, however, the 
underwriter at the first level of authority can make a decision, at 120, he will do 
so. If he chooses to decline the policy, the information therein is delegated to 
the "dead risk" file, at 126, where it is stored for later statistical analysis. If 
he chooses to accept the policy, it will be issued and communicated to a batch 
system 128. 

Detailed Description Text (50) : 

FIG. 2D is a detailed flow diagram of the functions performed by the operations 
level indicated generally at 55 of FIG. 2A and discussed above. Entry into the 
operations level is accomplished in the same manner as that of the underwriting 
level. Upon entry into the operations level the menu for operations is generated at 
48 and the operation functions are chosen at 54. The user then reviews the work to 
do, which is displayed in an "in-box" 130, and he reviews the specific error 
listing, at 132. Where possible, the operator contacts the agent for clarification 
of the information submitted or for missing information necessary to process the 
request, as indicated at 134. If this information is available from the agent the 
operator edits that information and enters it into the central processor data bank, 
at 136. 

Detailed Description Text (52) : 

FIGS. 2E-2F show a detailed flow chart of the communication to batch function 
disclosed generally at 104 of FIG. 2B. Once the policy has reached this point in 
processing, it has been approved by the client and further approved by the 
underwriter and is prepared for printing and mailing to the client. In step 148 the 
policy is taken from the issue step 106 and run through a series of processing 
inquiries 150-168. The first of these inquiries determines if further processing is 
necessary based upon certain predetermined characteristics which would require that 
the policy be processed out-of-sequence . Such characteristics include the presence 
of a cancellation notice, a nonpayment of premium notice, or failure to pay an 
installment charge. It will be readily apparent to one of ordinary skill in this 
art that these criteria could be varied from system to system to suit the company's 
needs. If no further processing is necessary, the system determines, at 154, if an 
MVR is necessayy. If so, a report is ordered at 156 (for motor vehicle policies 
only) . If no MVR report is required, the system determines at 158 whether or not an 
appraisal is necessary {for personal articles coverage or home policies) . If so, 
the appraisal is ordered at 160. If no appraisal is necessary the system determines 
at 162 whether or not certain statistics required by state government are 
necessary. If these statistics are necessary a statistical report is processed at 
164. If no statistical report is required, the system determines at 166 whether or 
not a quality control update is necessary. If such a report is required, an update 
is provided to the quality control file at 168. If not, the command is given to 
produce the contract policy 17 0. This command further generates the approval to 
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produce documents necessary to the contract policy such as coverage summaries, rate 
sheets, mortgage notices, countersigning notices, state notices, and the like. 

Detailed Description Text (58) : 

If the agent does not select the "action delete" function, an add or update 
operation is executed. The system determines whether or not a further home is to be 
added to the policy by generating request 226. If the response to this reuuest is 
affirmative the system automatically sets the data base fields concerning the new 
home to (0) and presents an appropriate screen to the agent requesting entry of the 
necessary information. The fields necessary to write the policy on the new home are 
highlighted, at 228, and the system then proceeds to edit step 234. 

Detailed Description Text (62) : 

A user of the system enters the system in the same method as described above and, 
in response, the system generates an action request 288, for example, "delete?" 
wherein coverage or risks, for example, may be deleted. If the user responds in the 
affirmative, a new request is generated inquiring if a quotation of new business is 
requested . If this inquiry 290 is answered in the affirmative, the system at 292 
automatically deletes the existing automobile from the insurance policy, and 
proceeds to step 294. If the response to inquiry 290 is negative, the system 
generates a screen containing all data on the automobile to be deleted and 
calculates, at 296, any return of premium required. The system then proceeds to 
step 298. 

Detailed Description Text (73) : 

FIG. 10B is the next screen to appear in response to the information entered on the 
screen shown in FIG. 10A. This screen appears with all "Y/N" (or yes/no) fields set 
to "N" except the last field 386 which is set to "Y." The particular information 
fields which are highlighted on this screen are indicated at 364-386 and are 
displayed for confirmation or entry by the agent. The "date received" field 368 and 
"date requested " field 370 are automatically set to the current date and the 
"writing company" field 378 is automatically set to "Federal" since this is the 
most commonly used entry in insurance writing by the assignee of the present 
invention. These entries are not fixed, however, and can be changed by the agent. 
Under the "coverages requested " field, the agent indicates what type of insurance 
coverage his client wishes. (In this case, the "homes/contents" and "valuable 
articles" are indicated in the affirmative.) The effective date of the policy is 
also indicated at 374 and the expiration date is generated to be a predetermined 
amount of time after the effective date shown at 376. The "producer number" field 
380 is highlighted to allow for agent identification and quality control. The 
"agency bill" field 382 is highlighted to indicate whether the agent will bill the 
client or, in the alternative, if the company should bill the client directly. The 
final two fields (the mailing instructions field 384 and the field indicating 
whether or not the policy is written in the name of an individual) are necessary 
items in compiling the final policy . The coverages requested at 372 are use to 
determine the sequence of screens that appear next and also affect the highlighting 
on later screen. More specifically, any information ettered at this stage which 
might appear on a later screen is picked up and inserted into the latter screen 
without requiring a second manual entry by the agent. 

Detailed Description Text (79) : 

Once all of this data has been entered by the agent and edited and evaluated by the 
system, the premium quotation is calculated and presented to the agent and/or 
client in the policy premium summary screen shown at FIG. 10G. This premium summary 
is itemized and is presented adjacent to the risk shown at 424. If the client 
approves the policy and the premium, the selection mode "issue" is entered by the 
agent and, assuming that the policy did not contain any predetermined criteria 
requiring non-concurrent underwriting, the screen shown in FIG. 10H is generated 
indicating that the policy has been issued as requested. Had the information 
entered contained predetermined parameters indicating that the risk was non- 
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concurrent, the message "your policy has been sent to underwriting for review" 
would appear. 

Detailed Description Text {84): 

The entered driver information is confirmed by the agent and is stored. The system 
then generates the screen requesting information regarding the vehicle. This screen 
is shown in FIG. 11D. On that screen, data fields indicated at 450-482 are 
highlighted either for entry or for confirmation by the agent. If, in the 
alternative, the client requests an excess-only policy, only data fields directed 
to vehicle year, make, model and type code are highlighted. A unique feature of 
this system is that some of the information requested in the data fields is 
generated from information previously entered either in the client or policy data 
bases. {One example of this utility is that the average retail cost of the vehicle 
can be determined from stored look-up tables and inserted if, at any point, the 
VIN/serial number of the vehicle to be insured has been entered into the data base. 
If that information is not available, however, it can be input at the time of the 
request for quotation. As dsscribed above, all "Y/N" fields are set to "N" and the 
agent selects the appropriate responses. The data fields requesting the garage 
location 472, county, state, zip code, territory and city/county codes, are 
automatically ceded from the primary residence location indicated in the existing 
policy . This information can be altered where necessary by the agent. Once this 
information has been entered, an edit and error analysis step is conducted and 
additional fields may be highlighted for the entry of additional information 
depending upon the data that already has been entered. Should more information be 
required, particular information fields are highlighted and an error message is 
returned to the screen. A sample of this type of message is shown in FIG. HE. In 
this case, the vehicle entered is to be registered in a state which has imposed 
state-mandated coverages such as uninsured motorist or no-fault coverage. This 
screen is designed as a flag to indicate to the agent that additional coverage must 
be written in order to satisfy state requirements. 

Detailed Description Paragraph Table (1) : 

PROCESSING CLERK UNDERWRITER AGENT 

build prospect build prospect build prospect 

quote quote quote process: inquiry; process; new line inforce new line endorsement 
quotes endorsement cancellation losses cancellation renewal conversion prospect 
renewal conversion reinstatement in process inquiry; inquiry; billing inforce 
inforce reports losses losses underwriting ; prospect prospect approve in process in 
process decline billing billing suspend/release reports reports (with notes 
electronic mail authority) order reports modification (contract/premium) 
cancellation reinstatement electronic mail 



CLAIMS : 

2. A computerized insurance system as in claim 1 which further comprises 
underwriter review means for electronic video display to the underwriter of risk 
and client information that has been written into said data bank and including 
manually operable means for approving, modifying and/or disproving requested 
insurance contacts. 

14. a computerized insurance system as in claim 8 which further comprises means for 
providing electronic video display of the insurance contract documents for final 
approval, modification and/or disapproval by an underwriter . 

15. A computerized insurance system as in claim 14 which further comprises keyboard 
means for communicating with said processing means, said keyboard means being 
operable by said underwriter to approve, modify or disapprove said insurance 
contract documents. 

18. A method as in claim 17, further comprising the steps of: 
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electronically displaying said insurance contract documents to an underwriter for 
aprroval, modification and/or disapproval; 

transmitting data representing approval, modification and/or disapproval to said 
data bank to store approval, modification and/or disapproval of said documents; and 

electronically indicating the approval, modification and/or disapproval of said 
documents . 

22. A computerized insurance system as in claim 21 which further copprises 
underwriter review means for displaying risk and client information that has been 
written into said data bank and including manually operable means for approving, 
modifying and/or disproving requested insurance contracts. 

23. A computerized insurance system for preparing and processing applications for 
insurance and premium quotations, and for preparing and writing insurance contracts 
requested by clients, said system comprising: 

processing means, including an interactive data bank into which data is written add 
from which data is read, said data bank storing information regarding a risk to be 
insured, client information, insurance premium information and the full text of all 
contract provisions 

terminal means for interactively communicating on-line with said processing means 
and accessible by an operator to produce requests and to enter information and/or 
retrieve information for writing into and/or reading from said interactive data 
bank; 

display means for displaying information that is entered an retrieved; 

means for automatically detectin;g certain predetermined criteria relating to the 
insured risk to trigger underwriter review only if those criteria are met 

merging means included in said processing means for reading out from said data bank 
selected client information and only the text data of the those contract provisions 
which apply to a paraticular contract and merging said read out client information 
and said read out particularized text data to compile final insurance contract 
documents tailored to each client; and 

print means coupled to said merging means for printing said final insurance 
contracts : 
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